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G. P. S. MANAGEMENT SYSTEM 



BACKGROUND 
Field of the Invention. 

The present invention relates to an application of Global Positioning Satellite 
(G.P.S.) technology. More particularly, the present invention relates to a system for 
managing the tasks and understanding the behavior of its employees. 

Background of the Invention. 

(Conventional G.P.S. systems generally include a single G.P.S. receiver. The 
receiver is in constant communication with a network of G.P.S. sateUites. The 
G.P.S. satelhtes transmit signals, and based on those signals, the receiver 
determines its own position. In this way, the user of the G.P.S. imit can determine 
its position anywhere in the world. 

One of the drawbacks of conventional G.P.S. systems is the local and isolated 
natm-e of the G.P.S. information. Ciirrently, the position information is only sent to 
the local user and the location history, or where the user has been, cannot be 
determined. Furthermore, conventional G.P.S. systems do not allow centralized 
storage and processing of information and conventional G.P.S. systems cannot track 
multiple G.P.S. users. If G.P.S. technology were apphed to a vehicle, present G.P.S. 



applications only allow the operator of the vehicle to know the present location of 
the vehicle. 

These shortcomings of current, isolated G.P.S. units, makes management of 
multiple vehicles using G.P.S. information difficult or impossible because the G.P.S. 
information is not collected and analyzed. 

SUMMARY OF THE INVENTION 

The invention provides a system that can monitor and track one or more 
remote units firom a central location. The present invention includes provisions for 
collecting, remotely storing, transmitting, centrally storing and analyzing G.P.S. 
data and other data, from a central location. The invention uses GPS data, as well 
as other types of data, to ascertain the current, as well as past locations of the 
remote xmits. 

In one aspect of the invention, the central location has at least one 
predetermined parameter with a range of values. The central location receives 
information from the remote units and compares that information with the 
predetermined parameter. If the information received from the vehicle is outside of 
the range of predetermined values, the system notes an exception. 

In another aspect of the invention, a remote unit is equipped with an alert 
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call functionality. The system includes provisions that allow technicians or users of 
the system to call for help by touching one button on a signaling device. The remote 
unit communicates the alert call to the central location and the central location 
contacts local authorities to send help. Optionally, G.P.S. data and other local 
5 information can also be forwarded to assist the local authorities. The signaling 
device can be a button disposed within easy reach of the technician or user or the 
signaling device can be a remote alert transmitter that wirelessly communicates 
y with the remote unit. 

^ In another aspect of the invention, the system includes provisions that allow 

lips 

ylO information stored in the remote imit to be transmitted to the central location 

M= during periods of relative inactivity. This feature aDows information to be 

p transferred from the remote unit to the central location without interfering with the 

2 fimction of the system during busy or active periods of time. 



15 BRIEF DESCRIPTION OP THE DRAWINGS 



Figure 1 is a schematic drawing of a preferred embodiment of an in-vehicle 
control unit according to the present invention. 



Figure 2 is a top view of a preferred embodiment of a remote alert transmitter 
according to the present invention. 
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Figure 3 is a schematic diagram of a preferred embodiment of an alert call 
center, according to the present invention. 

Figure 4 is a flow diagram for a first scenario of a preferred embodiment of an 
alert call center, according to the present invention. 

Figure 5 is a flow diagram for a second scenario of a preferred embodiment of 
an alert call center, according to the present invention. 

Figvire 6 is a flow diagram for a third scenario of a preferred embodiment of 
an alert call center, according to the present invention. 

Figure 7 is an example of a preferred manager report, according to the 
present invention. 

Figure 8 is an example of a preferred a weekly division report, according to 
the present invention. 

Figure 9 is a continuation of Figure 8 and is an example of a preferred weekly 
division report, according to the present invention. 

Figure 10 is an example of a preferred supervisor report, according to the 
present invention. 

Figure 11 is an example of a preferred weekly statistics report, according to 
the present invention. 



Figure 12 is a continuation of Figure 11 and is an example of a preferred 
weekly statistics report, according to the present invention. 

Figure 13 is an example of a preferred daily route history report, according to 
the present invention. 

5 Figure 14 is an example of a preferred route history report, according to the 

present invention. 

Q 

S Figure 15 is an example of a graphical route history, according to the present 

m invention. 

r Figure 16 is an example of an exception report, according to the present 

ItlO invention. 

rf Figure 17 is an example of a current location report, according to the present 

invention. 

Figure 18 is an example of a preferred technician attributes report, according 
to the present invention. 

15 Figure 19 is a schematic diagram of a preferred embodiment of a central 

office, according to the present invention. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE 
INVENTION 

/. Overview 

The invention generally allows accurate and convenient tracking and 
management of multiple G.F.S.-equipped remote entities. The entity can be a 
vehicle, a person, or any other mobile object that has G.P.S. equipment. The system 
can track G.P.S. information only, other non-G.P.S. information only, or a 
combination of G.P.S. information and other non-G.P.S. information. While the 
invention has broad application to any mobile entity, for purposes of darity the 
following disclosure will be limited to a preferred embodiment of the invention: a 
G.P.S. equipped vehicle. 

In the preferred embodiment, the system tracks various parameters of a 
vehicle at all times, including both G.P.S. and non-G.P.S. information. The system 
monitors a vehicle's location, speed, and information regarding other vehicle sub- 
systems such as the ignition switch. Preferably, this information is collected by 
devices located within or on the vehicle. The information is then transmitted 
directly to a central location, or stored in the vehicle and transmitted at different 
times and even by different formats. 
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IL Exception Tracking 

The information is preferably collected at a central location and analyzed. 
Given the G.P.S. information and the ignition information, the behavior of the 
driver and technicians can be evaluated. 

The invention includes provisions to simplify the amount of information that 
needs to be reviewed by managers. To simplify the analysis of the data by 
management personnel and to reduce the data to instances where management 
should be informed of certain types of behavior, the invention prefers the use of 
exception tracking. 

Exception tracking is when ordinary behavior or conditions are ignored and 
only events that fall outside certain predetermined boxmdaries are displayed or 
highlighted. In other words, exceptions are events or conditions that result from a 
violation of predefined parameter thresholds. 

Preferably, the system tracks exceptions by analysis of vehicle location data, 
ignition on and off transitions, and other vehicle data provided by the G.P.S. 
equipment. 

Exceptions are determined by comparing the data obtained from the vehicle 
with exception parameters that are predefined individually for each vehicle or for 
groups of vehicles. In order to facihtate easy programming of the predefined 



parameters, the Mse of graphical user interfaces is preferred. Authorized users can 
define exception parameters. Exceptions can be processed as soon as the data is 
collected or exceptions can be stored and then processed at once. This processing 
can occur at predetermined periods of time, for example, every hour, every shift, or 
every day. Preferably, exception processing occurs as soon as the data is received 
&om a vehicle. 

At the beginning of a typical day or shift, the first ignition event, preferably 
determined by sensing a change in the vehicle's ignition switch, of the day or shift 
coupled with the time the vehicle leaves the service center could be used to 
determine the start of the driver's work day or shift. The system preferably 
mcludes an appropriate graphical user interface that aUows authorized users to 
specify service center and shift parameters for individual vehicles or groups of 
vehicles. 

A service center location can be designated in many suitable ways. The 
service center location could be selected from a drop down menu or, preferably, by 
selecting a point on a graphical map display. 

Shift parameters include thresholds for estabhshing a late departure time 
and an early return time to the service center. In other words, the system could be 
programmed with a certain predetermined time, for example 8:30am, the time when 
drivers and technicians for a given shift are expected to start their routes. If a 
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vehicle were to use its ignition and leave the service center after 8:30am, an 
exception would be logged. The start time, as well as every other shift parameter, 
can be customized and changed to suit any particular apphcation, vehicle, group of 
vehicle or shift. 

5 Similarly, the time the vehicle returns to the service station in the evening 

can also be monitored. The vehicle return time could be determined by an ignition 
H off event that occurred within a certain proximity to the service station. By using 

both the ignition off information and the G.P.S. location information, the system can 
determine when a vehicle has been returned to the service center. As with all of the 
other parameters, the system can be programmed with a preselected return time, 
for example, 5:30pm. And in this case, any vehicle returned too early, for example, 
I before 5:30pm would be noted by the system as an exception. 

In addition to the exceptions noted by the system, the system also maintains 
a record of departure and arrival times for all of the vehicles. The system records 
15 the time at which a vehicle leaves the service center at the beginning of a shift and 
the system records the time at which the vehicle returns to the service center. 

Authorized users can specify the accuracy of this data. In other words, 
authorized users can specify the time measxmng parameter. For example, if an 
authorized user specified 10 minutes as the time measuring parameter, then all of 
20 the data would be accurate to the nearest 10 minute interval. Similarly, if the 



authorized user specified a time measuring parameter of one hour, the data would 
be accurate to the nearest hour. Clearly, any suitable time measuring parameter 
could used. 

During the day, the vehicle speed could be determined based on time and 
5 location information retrieved from the G.P.S. system and sent to the central 
location by the vehicle. The system preferably includes an appropriate graphical 
user interface to allow authorized users to specify excessive speed parameters for 
individual vehicles or groups of vehicles. 

The excessive speed parameter can be varied and is adjustable within a range 
10 of values. Preferably, the range is from 5 miles per hour to 100 miles per hour. 
When the excessive speed parameter is exceeded, the excessive speed exception is 
noted and logged for that vehicle, along with a time stamp and location information. 

The system can also monitor idle time. The idle time feature determines if a 
vehicle has been at a stationary point for an extended period of time. Using this 
15 feattire, the system informs users if a driver is possibly participating in activities 
that are outside the scope of the employee's duties. For example, the idle parameter 
cotdd be set for two hours and any vehicle idle for more than two hours would be 
noted as an exception. 

The idle feature can also be combined with the location information. The idle 
20 parameter could be adjusted based on location. For example, if the vehicle is in the 
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parking lot of a movie theater and is idle for one hour, half of the idle time generally 
permitted, the system may note an exception. 

The system also includes provisions for monitoring certain regions by placing 
a parameter around those areas or regions. Those regions woiild be monitored and 
5 if the vehicle reaches that region (for example, a restricted region) or if the vehicle 
fails to reach that region (for example, a chent site), than an exception would be 
U noted. 

Qi The system preferably includes an appropriate graphical user interface that 

m allows authorized users to specify stationary point parameters for individual 
f 10 vehicles or groups of vehicles. The length of time can be adjusted to any desired 
ri value. For example, the maximum permitted stationary time can be adjustable 
O within a range of values between 3 minutes and 300 minutes, with an additional 

option for no time limit. The no time limit feature effectively cancels the idle time 

feature. 

15 When the maximum permitted stationary time parameter is exceeded 

without movement of the vehicle, the stationary point exception is logged for that 
vehicle. Movement can be defined in many ways and the definition of movement 
can be adjusted. In a preferred embodiment, the definition of movement, for 
purposes of the stationary point parameter, is a location change greater than ttie 

20 maximum resolution of the G.P.S. receiver. 
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Grouping is another phenomenon monitored by the system. Grouping is 
when multiple vehicles are in close proximity to one another. The G.P.S. system 
according to the invention, analyzes the route histories of every vehicle in a district 
or division to determine if multiple vehicles have been stationary at the same 
location at the same time during the day. The system preferably includes a 
graphical user interface that allows authorized users to specify co-location distance 
and duration parameters for individual vehicles. 

The co-location distance between vehicles can be adjusted to any desired 
range, for example the co-location distance could range between 50 to 1500 feet. 
Likewise, the minimum co-location duration, or the time the group of vehicles needs 
to be within the co-location distance can also be adjustable. For example, a range of 
values from 5 minutes to 2 hours coxild be used. 

If two or more vehicles are stationary within the defined distance of each 
other at the same time and remain so for itnore than the defined duration, the Group 
of Vehicles (GOV) exception is recorded for all of the co-located vehicles in the 
group. 

The system can also utilize the service center and shift parameters defined 
for the "Out of Gate/Back to Bam" exception to track revisits to the service center. 
The triggering event is when a vehicle is located at the service center after the "Out 
of Gate" time. An exception can be logged for that event alone. However, additional 
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parameters, like the duration of the visit and additional revisits can also be used to 
avoid unnecessary recording of minor or permissible revisits. 

For example, the duration time could be set to any desired time. The 
invention contemplates a range of between 1 and 120 minutes, and preferably 
aroiind 3 minutes. In other words, in the preferred embodiment, an exception 
would only be logged if the vehicle remained at the service center for more than 3 
minutes. 

Similarly, the number of revisits could also be selected. The excessive 
revisits parameter can be adjusted within a range of values from 1 to 10 revisits to 
the service center. For example, if the revisit parameter were set to two revisits, no 
exception would be logged unless the vehicle returned to the service center two or 
more times during a shift. Of course the number of revisits could be adjusted and 
changed to suit particular conditions. In other words, the system would assume, if 
the number of revisits parameter were set to two, that the first revisit would be 
legitimate and any additional revisits questionable and reqmring management 
scrutiny. 

In addition to logging the exceptions to the revisit parameter, the system also 
maintains a record of the number and duration of revisits to the service center for 
every vehicle. 

Like the other parameters, the system preferably includes an appropriate 
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graphical user interface that allows authorized users to specify excessive revisit 
parameters for individual vehicles or various groups of vehicles. 

Windshield time is a parameter that measures the amount of time the vehicle 
is actually driven. The system preferably includes an appropriate graphical user 
interface that allows authorized users to specify windshield time parameters for 
individual vehicles or groups of vehicles. 

The windshield time parameter can have a range of values and preferably 
can be adjustable within a range of 1 hour to 8 hours of total driving time. When 
the actual windshield time falls outside the parameter, the system logs a windshield 
time exception. Actual windshield time can be determined in many ways, but is 
preferably determined by using travel time and distance* 

The ignition on parameter measures the total or cumulative time running 
time of the vehicle. The system preferably includes an appropriate graphical user 
interface that allows authorized users to specify cumxilative ignition on time 
parameters for individual vehicles or groups of vehicles. 

The parameter can be adjusted for different situations. Preferably, the 
cumulative ignition on time is adjustable within a range of values from 15 minutes 
to 8 hours. The cumulative ignition on time is determined by adding all of the 
ignition on intervals for a given time period. Preferably, this time period is either a 
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calendar day or a shift. 

When the cumulative ignition on time exceeds the windshield time by a 
specified value, the system notes an exception. Even if the cxunulative ignition on 
time is within the selected parameter, the system records the cumulative ignition 
5 on time. 

The mileage parameter measures the total number of miles traveled by a 
O vehicle during a preselected time interval. The interval can be a calendar day, a 
5 shift, or any other desired time interval. The system preferably includes an 
7^ appropriate graphical user interfeice that allows authorized users to specify 
rio cumulative ignition on time parameters for individual vehicles or groups of vehicles. 

s 

fy Any desired mileage parameter can be set, however, an adjustable range of between 
y 10 miles to 500 miles is preferred. The system logs the total number of miles and 

also logs exceptions when the actual mileage falls outside the preset mileage 

parameter. 

15 If the G.P.S. signal were lost during the day, for example, if the vehicle enters 

a basement of a building, that event would be logged along with a time stamp. 
Preferably, a lost G.P.S. signal event also includes the situation where the G.P.S. 
receiver eqmpment on a vehicle is incapable of accurately determining vehicle 
location. Preferably, the initial warm-up and lock-on times following an ignition on 

20 event would not be considered a loss of G.P.S. signal. The I.C.U. stores a loss of 
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G.P.S. signal exception report with a time stamp when the G.P.S. receiver is 
incapable of accurately determining the vehicle location. All G.P.S. data received by 
the In-Vehicle Control Unit (LCU) from the G.P.S. receiver includes the G.P.S. 
signal status information. The signal status is used to determine the accuracy of 
the vehicle location. If the G.P.S. signal status is determined to be inaccurate, an 
exception report is logged by the system. Conventional G.P.S. receivers send out an 
error codes when they are unable to accurately determine their own location. The 
ICU uses this conventional feature of G.P.S. receivers to determine a loss of G.P.S. 
signal. An indication that the G.P.S. signal had been lost and the associated time 
can also be provided on all of the various reports for the vehicle or technician. 



III. System Components 

The invention includes various components that support the functions 
disclosed above. In the preferred embodiment, the components include an in-vehide 
control unit, a remote alert transmitter and a central office. 

A vehicle according to the invention, preferably includes provisions that aUow 
the vehicle to receive data from various soxu-ces and provisions that allow the 
vehicle to commtmicate with other vehicles, with a central office, and with others 
via a cellular phone connection. Preferably, all of these functions are handled by a 
smgle unit, the in-vehicle control unit, ICU 100, shown schematically in Figure 1. 
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The ICU 100 is preferably located either imdemeath the front passenger seat or 
attached to the back of the front passenger seat. 

The ICU 100 includes various connections. One connection 108 is adapted to 
receive an antenna 110. Similarly, there is a connection 104 for the G.P.S. receiver 
106. A connection 112 accepts power from a motor vehicle battery 114. An ignition 
sensor 116 communicates with the ICU 100 via connection 118. The ignition sensor 
116 determines if an ignition on event or an ignition off event has occurred. There 
is also, preferably, a handset connection 120 for a cellular telephone handset 122. 
The ICU 100 also includes an alert call connection 124 that receives the input of an 
in-vehicle alert call button 126. The ICU 100 has a security tag 128 that is tamper- 
evident. 

The ICU 100 also has components that perform the computing and 
communications tasks. In addition to a processor 102, the ICU can optionally have 
at least one or more of the following components: a satellite modem 130, a wireless 
data modem 140, a ceHular module 150, and/or a G.P.S. receiver 106. The ICU 100 
also includes an antenna connection 132 for an RF antenna 134 to receive signals 
from a remote alert transmitter 200. Preferably, the processor 102 is an Intel x386 
based processor, and the G.P.S. receiver 106 is a 12 channel receiver. The cellular 
module includes a cellular modem and a cellular telephone system. Preferably, the 
ICU 100 includes every communications component for which service is available in 
the particular area where the ICU 100 is used. In an exemplary embodiment of the 
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invention, the ICU 100 includes all of the communications components. 

While the in-vehicle alert button allows technicians and users to call for help 
while they are in the vehicle, the invention also includes provisions that allow users 
or technicians to call for help or request immediate assistance even when they are 
outside of the vehicle or away from the vehicle. Preferably, a remote alert 
transmitter (RAT), small enough to be carried on a person, can be used to activate 
the alert call. 

Physically, the RAT 200 is approximately the size and shape of a keyless 
entry key fob. It is preferably smaller than a conventional pager, and is small 
enough to be carried in a pocket or attached to a belt by a belt chp. As shown in 
figure 2, the RAT includes a prominent button 202 that is used to send a signal to 
the ICU 100. The signal can be carried on any electromagnetic wave, although a 
radio frequency signal is preferred. 

The system preferably includes a central office. Referring to Figiire 19, which 
is a schematic diagram of a preferred central office 1900, the preferred central office 
includes provisions to receive and process information sent to it by the other 
components of the preferred system. 

The preferred central office 1900 includes a wireless communications device 
1902. This device permits the central office 1900 to communicate with ICITs 
deployed throughout a region. The wireless communications device 1902 can 
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function using any desired communications medium or protocol including satellite, 
cellular, and/or wireless data network. Cellular and/or wireless data network are 
preferred. Preferably, the IClTs use Mobitecli modems to transmit information to 
the central office 1900 and the wireless communications device 1902 includes 
provisions that allow it to communicate with the Mobitech modems. The wireless 
communications device 1902 can receive data in any format. However, preferably 
the wireless communications device 1902 receives data as a flat file. 

A second communications device 1904 provides an interface to the alert call 
center 300 (see Figure 3). The second communications device 1904 assists the 
central office 1900 in receiving information from the alert call center 300. Tbe 
second communications device 1904 can receive data from the alert call center 300 
in any suitable format or protocol, however a TCP/IP connection to the alert call 
center 300 is preferred. The alert call center 300 is disclosed in greater detail 
below. 

Both of the communications devices 1902 and 1904 send data collected from 
their respective sources to a processor 1906, Processor 1906 can be a discrete 
computer or a computer component or could be an apphcation running on a 
computer system. Processor 1906 receives information from the two 
communications devices 1902 and 1904 and prepares the information for storage in 
storage device 1908. Storage device 1908 can be a server or a database. Once the 
information is stored on storage device 1908, apphcations 1910 communicate with 
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storage device 1908 to prepare reports and perform other functions with the 
information on storage device 1908. The applications 1910 preferably prepare the 
reports disclosed below and shown in Figures 7-18. 

IV. Alert Calls 

The invention includes provisions that allow a technician to signal an alert 
that results in the immediate transmission of an alert call message. There are 
many ways a technician can signal an alert. Alerts could also be automatically 
generated by the system based upon certain predetermined conditions. Preferably, 
there are at least two alert signaling devices. The first is an alert button located in 
the vehicle, and the second is a wireless device that is preferably smaU and worn by 
the technician, such as a remote alert transmitter (RAT). Both of these devices will 
be described in greater detail below. 

When an alert call message is generated, that message is transmitted to the 
appropriate Alert Call Center or ACC. Preferably, the alert call message is 
transmitted via a wireless data system or via satellite. If the wireless data system 
or satellite coverage is not available, the alert call message is preferably then 
transmitted via a cellular telephone network to the appropriate ACC. 

The ACC can be separate from the central office, coincide somewhat with the 
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central location (in other words, portions or elements of the ACC and the central 
office share facihties or resoiirces), or be part of the central office. 

Figure 3 shows a schematic diagram of a preferred embodiment of an ACC 
300. The alert call center 300 includes devices that allow it to communicate with 
various other components of the preferred system, including a wireless 
communications device 302, and a connection 304 for communicating with a central 
office 1900 (see Figure 19). The wireless communications device 302 is designed to 
wirelessly commxmicate with an ICU 100 (see Figure 1) equipped vehicle 306. Any 
wireless transmission medium or protocol may be employed. However, a wireless 
data network and/or cellular network is the preferred wireless transmission 
medium of the present invention. 

A number of administrators using a suitable number of personal computers 
308 monitor the status of vehicles and technicians and watch for technicians who 
request assistance. The personal computers 308 are preferably equipped with web 
browsers so that the administrators can search and update emergency contact 
information. The administrators also have access to one or more databases that 
contain relevant information. In the preferred embodiment, the administrators 
have access to a database 310 that contains information regarding the attributes of 
every technician within their region. Preferably, the administrators also have 
access to a G.LS. (Geographical Information Street Map) system that allows the 
technicians to graphically display street maps. The preferred embodiment also 
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provides administrator access to ESN (Emergency Services Number) and/or PSAP 
(Public Safety Answering Point) information. Preferably, the ACC 300 is in 
communication with the central office 1900 (see Figure 19) via a connection 304. 

The contents of the alert call message can be varied to suit a particular 
5 application. Preferably, the alert call message includes the current location of the 
vehicle, the vehicle identifier, the technician identifier, and the cellular telephone 
number of the vehicle. 

The operating times of the ACC can be adjusted to suit particular needs and 
budgets. However, the preferred embodiment of the invention envisions an ACC 

10 that monitors alert calls 24 hours per day, 7 days per week. Preferably, the ACC is 
capable of monitoring the entire operating region of the system, or the company 
employing the system, and is arranged in a manner that allows personnel working 
at the ACC to have ready access to the signaling technician's attributes that permit 
the identification and contact of the technidan based on the content of the alert 

15 message. 

Preferably, the ACC has the abihty to quickly determine the street address of 
the vehicle location based on the content of the alert message. Additionally, as 
noted above, the ACC preferably has ready access to the appropriate emergency 
telephone numbers for any vehicle location monitored by the ACC. 

20 Figxu-es 4-6 are flow diagrams showing the steps the ACC preferably follows 
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to process alerts received from vehicles. In Figures 4 - 6, an alert has been 
transmitted to the ACC, the alert has been received by the ACC and an ACC 
operator has called the vehicle that originated ttie alert message. Figure 4 shows 
the preferred steps that are followed if a technician answers the call placed by the 
ACC operator. Figure 5 shows the preferred steps that are followed if the call from 
the ACC operator is not answered by the technician. And Figure 6 shows an 
alternate embodiment and the preferred steps that are followed after an alert 
message has been received. Figure 6 discloses the steps that are preferably followed 
when a second alert message is received from ttie same vehicle. The embodiment 
shown in Figure 6 can be a separate embodiment, or the steps shown in Figure 6 
can be combined witii other embodiments such as the embodiment shown in Figures 
4 and 5, so that other embodiments can include a procedure to deal with second 
alerts received from the same vehicle. 

Referring to Figure 4, a local alert button is pressed in step 402 and an alarm 
is received at the ACC in step 404, initiating action by ACC operators. The ACC is 
also sometimes referred to as an Emergency Control Center (ECC). In step 406, 
ACC operators place a cellular call to the technician's vehicle that originated the 
alert. Assuming that the call is answered by the technician in step 408, the ACC 
operator asks for a password in step 410. If a password is not given or is incorrect, 
then the call is terminated and the ACC operator calls 911 or another emergency 
number in step 412. If the password is correctly given, then the ACC operator 
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determines if the vehicle is at a company location in step 414. 

If, in step 414, the vehicle is determined to be at a company location, then in 
step 416 the ACC operator asks if assistance is required. A company location is any 
location that is within the control of the company, and has supervisor on staff at 
that location. If the technician indicates that assistance is required, then in step 
418 the ACC confirms the safety of the technician and calls the supervisor or 
manager of the facility where the vehicle is located. If the technician indicates that 
assistance is not reqioired, ilie ACC operator still confirms the safety of the 
technician and terminates the call. 

In step 414, the ACC operator determined if the vehicle was at a location 
other than a company location. Step 422 is the step after the ACC operator has 
determined that the vehicle is at a location other than a company location, and the 
ACC operator follows the procedures disclosed in step 424. In step 424 the ACC 
operator verifies the safety of the technician. If the alert was sent in error, or the 
alert was false for some other reason, then the alert session is terminated. 
Additionally, in step 424, if the technician requests assistance, the ACC operator 
calls 911 or another emergency nimiber and requests that assistance be sent to the 
vehicle. The alert session is terminated upon arrival of the assistance. 

Referring to Figure 5, a local alert button is pressed in step 502 and an alarm 
is received at the ACC in step 504, initiating action by ACC operators. ACC 
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operators place a ceEular caU to the technician's vehicle that originated the alert in 
step 506. In this case, the ACC determines that the call is not answered by the 
technician in step 508. The ACC operator determines if the alert was sent by a 
vehicle located in a company location in step 510. K so, the ACC operator informs 
the supervisor or manager of the facihty to assist the technician in step 512. If the 
vehicle is not at a company location, then the ACC operator calls 911 or another 
emergency number and requests that assistance be sent to the vehicle in step 514. 

Referring to Figure 6, a local alert button is pressed in step 602 and an alarm 
is received at the ACC in step 604 . In this embodiment, if a second alarm is 
received in step 606, then the ACC operator calls 911 or another emergency number 
and requests that assistance be sent to the vehicle in step 608. If a second alarm is 
not received, then the ACC operator determines if the vehicle is located in a 
company location in step 610. 

If the vehicle is at a company location, then the ACC operator calls the 
vehicle in step 612. If the ACC operator's call is answered by the technician, in step 
614 the ACC operator asks for a password. If a password is not given or is 
incorrect, then in step 616 the ACC operator notifies the supervisor or manager of 
the facility and documents information related to the alert call. If the password is 
given correctly, then in step 618 the ACC operator verifies the safety of the 
technician and either terminates the call or calls 911 or another emergency number 
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if necessary. 

If the call is not answered by the technician in step 612, then in step 620 the 
ACC operator waits for a call back within 10 minutes. If the technician answers the 
page and calls the ACC back, then the ACC operator verifies the safety of the 
5 technician and either terminates the call or calls 911 or another emergency number 
in step 618, if necessary. If the technician fails to return the page, then the ACC 
^ operator notifies the supervisor or manager of the facility 622. 

^ If the vehicle is at a location other than a company location, in step 622 the 

m 

m ACC operator calls the vehicle. If the ACC operator's call is answered by the 

s 

Ml 

f 10 technician, the ACC operator asks for a password in step 624. If a password is not 
given or is incorrect, then the ACC operator calls 911 or another emergency number 

p in step 628 and monitors the location of the vehicle. If the password is correctly 
given, then the ACC operator verifies the safety of the technician and either 
terminates the call or calls 911 or another emergency number in step 630, if 
15 necessary. 

If the call is not answered by the technician in step 622, then the ACC 
operator waits for a page tech. call back within 10 minutes in step 632. If the 
technician answers the page and caUs the ACC back, then the ACC operator verifies 
the safety of the technician and either terminates the call or calls 911 or another 
20 emergency number in step 630, if necessary. If the technician fails to return the 
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page, then the ACC operator calls 911 or another emergency number in step 634. 



V. Communications 

The system can be implemented using a single communications medium or by 
using a variety of different communications media that allow communications 
between the central office and the vehicles. In the preferred embodiment, the 
system uses a variety of communications media. The system has the capabihty for 
transmitting and receiving data between the ICU and the data servers over various 
transmission media, including cellular, wireless data network, and satellite. 
Preferably, every vehicle contains a cellular modem and a wireless data modem, 
and each ICU incorporates provisions that either allow transmission via a satelUte 
network or provides convenient upgradability to satellite communication. 

The system preferably uses a cellular telephone network for two way data 
transmission between the central office and the ICUs. The cellular telephone 
network preferably provides full duplex, two-way voice communication. 

The vehicles may have the capability of commxmicating using a wireless data 
network. As noted above, the vehicles are preferably equipped with a wireless data 
modem. The wireless data network is the preferred data communication medium. 
However, if a wireless data network is not available, satellite networks may be 
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utilized. 

Vehicles may also communicate using a sateUite network. Those vehicles 
that communicate using a satellite network are preferably equipped with a sateUite 
modem, 

VI. Power Conservation Features 

The invention includes provisions to conserve power. When the system 
detects an ignition off condition, the system processes all of the computing steps 
associated with the detection of an ignition off condition, and then the ICU enters a 
"sleep" mode in order to reduce power consumption. When in sleep mode, power 
shall be supplied only to those components that must still function when the vehicle 
is not moving. 

During the "sleep mode" the alert call features, including the RAT (Remote 
Alert Transmitter) button, still function. The preferred way the system allows the 
alert call feature to function during a state of "sleep,'* such that the system comes 
out of sleep mode when the system senses an activation of a technician alert call, 
either from an in- vehicle button or a remote button, and the ICU comes out of the 
sleep mode long enough to perform alert call processing functions. 

System parameters, location of the vehicle, and other stored data is 
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maintained while the ICU is in sleep mode. Turning the vehicle ignition on causes 
the ICU to come out of the sleep mode and resume normal processing. 

Preferably, the ICU is designed to conserve power during all of its operating 
modes. Primary vehicle power consumption by all G.P.S. components within the 
5 vehicle should not to exceed 1 Amp hour for any twenty-four hour period. 

O VI/. Daily Batch Upload 

K The system includes provisions that allows the vehicles to send daily history 

r ' information to the central office. Although this daily transmission can occur at any 
fiO tune, it is preferred that the daily upload does not intrude into the function of the 
2 system during periods of active operation of the vehicle. The timing of the daily 
^ batch upload should preferably be coordinated to coincide with those tunes when 

the vehicle is not operational. For example, if a particular vehicle is scheduled to be 

operational from 8:00am to 6:00pm, that would mean that the vehicle is likely to be 
15 inactive from 6:00pm, through the night, until 8:00am the next morning. The 

timing of the daily batch upload would be selected to occur during that period of 

inactivity. 

Generally, during these periods of inactivity, the vehicle will be in sleep 
mode. The system includes provisions that brings the vehicle out of sleep mode to 
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perform the daily batch upload. Preferably, an automatic timer in the ICU 100 
wakes the vehicle up and brings the vehicle out of sleep mode. 

Any type of information can be uploaded from the vehicles to the central 
office dming the daily batch upload. However, a comprehensive data dump 
mcluding the following items of information are preferably transferred from the 
vehicle to the central office: daily history of location reports, ignition on and off 
transitions, alert calls, and other routine data. 

Any type of commiinications medium can be used to perform the daily batch 
processing, however, the invention prefers the use of a cellular network for daily 
batch uploading. In an exemplary embodiment of the invention, packetized data is 
transmitted via the cellular network to the central office. 

The system preferably includes an appropriate graphical user interface that 
allows authorized users to specify the time the daily batch upload takes place for 
individual vehicles or groups of vehicles. 

Daily batch uploads can be performed using the server "dial out" mode of 
estabhshing the connection between the central office and ICU. One way of 
implementing the "dial out" mode is to define a predetermined time when the 
central office will try to contact the ICU. The ICU, using its automatic timer, wakes 
up a short time before the predetermined time and awaits a communication fi"om 
the central office. The central office then, at the predetermined time, contacts the 
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ICU and requests a daily batch upload. The system can either initiate a central 
office to ICU transmission or an ICU to central of&ce transmission. Preferably, the 
ICU initiates the daily batch upload during off-peak times. 



VIL Near Real Time Data Upload 

Another feature of the present invention is the ability of the system to obtain 
information about all of the various vehicles in near real time. To accomplish this, 
the system includes provisions that allow vehicles to transfer information in near 
real time to the central office. The wireless data network or the satellite network is 
the preferred communications medium for this task. 

Although many types of information could be transferred in near real time to 
the central office, the invention prefers the near real time transmission of the 
following items of information: location information, ignition on and off transitions, 
alert calls, and other specified data in near real time. 

VIIL Data Output^ Reports 

The invention includes provisions for generating reports. Any type of report 
can be produced using the data collected from the vehicles. Four specific tjrpes of 
reports that may be produced include a route history, an exception report, a 
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periodic productivity analysis report, and an administrative report. Other reports 
may be generated by the system. 

Preferably, the reports are tailored to suit the organizational structure of the 
company employing the system. The following description of a preferred 
5 embodiment illustrates one apphcation of the G.P.S. management system where a 
company's organizational structure includes technicians who report to supervisors, 
U who in turn, report to managers. One supervisor is charge of about ten technicians 
2 and one manager oversees about ten supervisors. 

Jt=! The system preferably includes security options that hmit the access of the 

=.10 system to authorized users. The system includes provisions that only allow 

S r 

lU supervisory and management users to access specific technicians and vehicles that 
y are within the supervisor's or manager's organization. Preferably, the system 

includes a four tier hierarchy with system access granted according to standard 

protection procedures. 

15 Given the preferred organizational structure, the following reports may be 

generated. Beginning with the manager, managers could access the system and, 
among other options, view the reports online or print the reports. Preferably, the 
same information would be available in either format. If the reports are viewed on 
line, the reports would preferably allow the manager to use the online report to 

20 navigate to other portions of the report being viewed or to navigate to other reports. 
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Figure 7 shows an example of a manager report 700. The manager report 
700 includes a system name 702 - in this Example, the system name is "BellSouth 
GPS System." The manager report 700 could also include a reference name 704 of 
the report. In this embodiment, the reference name 704 of the report is "Manager 
Page." The manager report 700 can also preferably include the name of the 
manager 706, the division or branch 708 to which the manager is assigned, and a 
date 710. 

Manager report 700 could also mclude a list of other reports 712 that may be 
of interest to the manager. In the example shown in Figure 7, the hst of other 
reports 712 includes weekly and monthly statistics for different periods of time, for 
the particular division that that manager oversees. As shown in the manager 
report 700, that particular division is North Atlanta. Preferably, the online version 
of the manager report 700 allows the manager to retrieve and view a report that 
appears on the hst of reports 712 by selecting that report. For example, if the 
manager wanted to view the weekly statistics for the week ending 1/31/98, the 
manager could select the report 714 that corresponds to that time period and the 
system would retrieve that report, the weekly division reports 800 (shown in 
Figures 8 and 9) and allow the manager to view, send and manipulate weekly 
division reports 800. 

The manager report can also preferably include provisions that allow the 
manager to easily retrieve reports related to sub-divisions within the larger division 

33 



under the responsibility of the manager. Preferably, these sub-divisions are service 
centers located within the larger division. In the embodiment shown in Figure 7, 
the manager report 700 is for the North Atlanta division and the sub-divisions 716 
are service centers located at 14^ Street, Fairburn, Stockbridge, and Tucker. In a 
5 manner similar to the list of other reports 712, the manager report 700 preferably 
allows the manager to select one or more of the sub-divisions and retrieve 
information for that sub-division. 

Q Other sections of the manager report 700, including an options portion 718 

cji 

CP allow the manager to select various options. Some of the possible options include 
VllO the ability to locate a vehicle 720, to retrieve technician attributes 722 and vehicle 
attributes 724. The system can also provide drop down menus to assist in the 
selection of a vehicle or a technician. The manager report 700 can also preferably 

5 

include provisions that allow managers to perform other functions. These other 
functions can include the ability to generate daily route histories 726, generate 
15 productivity parameters 728, manage reporting parameters 730, and manage group 
assignments 732. 

Figures 8 and 9 show an example of a preferred weekly division report 800. 
The preferred weekly division report can include a title 802, a date range 804, a 
division 806, and a manager's name 808. Preferably, the weekly division report 800 
20 is organized by service center or by supervisor. In some cases, there is only one 
supervisor per service center, but the system provides flexibility to accommodate 
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other situations. 

The first section 810 of division report 800 relates to a particular service 
center and a particular supervisor and provides information about that service 
center. Some of the information in the first section 810 include a date, an average 
time out of the gate (the time the system detects the vehicle left the service center), 
an average back to bam (the time the system detects the vehicle returned to the 
service center), average work time (the total time between out of gate and back to 
bam minus windshield time), average windshield time (the time the system detects 
the vehicle to be driven or in motion), average engine run time, average engiae 
starts, average revisits (the number of times the vehicle revisited the service 
center), and average mileage. Because the information contained in the first section 
810 are averages, the figures represent the average of all of the technicians under 
the authority of the supervisor for that particular day. The bottom of the first 
section 810 can include a weekly average. 

The weekly division report 800 can also include other sections that give 
details of other service centers. In the embodiment shown in the Figiu-es 8 and 9, 
three other sections, a second section 820 that relates to the service center at 
Fairbum, a third section 830 that relates with Stockbridge and a fourth section 840 
regarding Tucker are also included in the weekly division report 800. Preferably, 
the other sections 820, 830, and 840, include substantially similar information to 
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that contained in the first region 810. 

Figure 10 shows an example of a preferred supervisor report 1000. The 
supervisor report 1000 preferably includes similar bibliographic information as the 
manager report 700 (see Figure 7) disclosed above. The supervisor report 1000 

5 includes a system name 1002, in this example, the system name is "BellSouth GPS 
System." The supervisor report 1000 can also include a reference name 1004 of the 
report. In this example, the reference name 1004 of the report is "Supervisor Page." 
The supervisor report 1000 can also preferably include the name 1006 of the 
supervisor, the service center 1008 where the supervisor has been assigned, and a 

10 date 1010. 

Supervisor report 1000 can also include a list of other reports 1012 that may 
be of interest to the supervisor. In the preferred example shown in Figure 10, the 
hst of other reports 1012 includes weekly and monthly statistics for different 
periods of time, for the particular service center overseen by that supervisor. The 
15 list of other reports 1012 also includes reports related to each individual technician 
that works under the supervisor. The report can be organized by a hst of daily 
reports for individual technicians followed by weekly statistics for the service 
center, and finally concluding with monthly statistics for the service center. 

Preferably, the online version of the supervisor report 1000 allows the 
20 supervisor to retrieve and view a report that appears on the list of reports 1012 by 
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selecting that report. For example, if the supervisor wants to view the weekly 
statistics for the week ending 1/31/98, the supervisor could select the report 1014 
that corresponds to that time period and the system would retrieve that report, the 
weekly statistical report 1100 (shown in Figures 11 and 12), and allow the 
supervisor to view, send, and manipulate the weekly statistical report 1100. 

The online version of the supervisor report 1000 preferably includes an 
options portion 1020 that allows the supervisor to review other types of information 
and request the system to perform other tasks. Some of the possible options include 
the abUity to locate a vehicle 1022, to retrieve technician attributes 1024 and 
vehicle attributes 1026. The system can also provide drop down menus to assist in 
the selection of a vehicle or a technician. The supervisor report 1000 can also 
preferably include provisions that allow supervisors to perform other functions. 
These other functions can include the ability to generate daily route histories 1028 
and generate productivity parameters 1030. 

Figures 11 and 12 show an example of a weekly statistical report 1100. The 
preferred weekly statistical report 1100 can include a title 1102, a date range 1104, 
a sub-division or service center 1106, and a supervisor's name 1108. Preferably, the 
weekly statistical report 1100 includes information regarding the technicians that 
are supervised by the supervisor. 

The first section 1110 of the weekly statistical report relates to a particular 

37 



technician and the technician's vehicle. While the weekly statistical report 1100 
can include a variety of information, the weekly statistical report 1100 preferably 
includes a group affiliation for the technician, a vehicle identifier, a technician 
identifier, a date, an out of the gate time (the time the system detects the vehicle 

5 left the service center), a back to barn time (the time the system detects the vehicle 
returned to the service center), work time (the total time between out of gate and 
back to barn minus windshield time), windshield time (the time the system detects 
the vehicle to be in motion), engine run time, engine starts, revisits (the number of 
times the vehicle revisited the service center), and mileage. The bottom of the first 

LO portion 1110 can include a weekly average for the technician. 

Similarly, the second section 1120 and the third section 1130 of the weekly 
statistical report can include similar information for other technicians. While 
preferred embodiment shows the weekly statistics for three technicians, the system 
could be used for any number of technicians. A lower section 1140 of the weekly 
15 report can include group averages and division averages. 

The information contained in this first section 1110 of the weekly statistics 
report 1100 related to technician ST109 can be combined with information related 
to other technicians, for example, technician ST 143 (shown in the second section 
1120), and technician ST152 (shown in the third section 1130). The information for 
20 a predetermined group of technicians can be combined to arrive at group averages. 
These group averages can be stored and can be made available to authorized users. 
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In addition, the information for all of the technicians in a service center or sub- 
division can be combined to arrive at averages for entire service centers. This 
averaged information can be stored and made available for authorized users. One 
example of information related to service center averages is shown in Figures 8 and 
5 9. 

Figiu'e 13 shows an example of a preferred daily route history report 1300, 
tr Like other reports, the daily route history report 1300 can include bibUographic 
5 information, including a title 1302, a technician identifier 1304, a vehicle identifier 

:5sas. 

Oh 

§1 1306, a date 1308, a name of the technician 1310, a group affUiation for the 

m 

^0 technician 1312, and the name of the service center 1314 associated with the 

technician. The daily route history 1300 is a detailed report that gives details about 
b the activities of a particular technician. Preferably, the daily route history 1300 
H uses information collected fi:om the technician's I.C.U. 100 (see Figure 1) to 

reconstruct the activities of the technician and other attributes of the technician or 
15 the technician's vehicle throughout a given day. Preferably, this information is in 
the form of a table 1320. 

The table 1320 preferably includes the following information: an item 
number, a time, a street address, a county and state, minutes, speed, and type of 
point. The system records information at predetermined periods of time and also 
20 records information when noteworthy events occur throughout the day. The table 
1320 captures nearly all of the information regarding the technician's location for 
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any given day. A lower section 1330 preferably includes additional information. 
Preferably, the lower portion 1330 includes the time out of gate, the back to barn 
time, windshield time, engine run time, mileage, and the number of starts. 

In addition to the daily route history 1300 shown in Figure 13, the preferred 
5 embodiment of the present invention includes several options and features that are 
available with the daily route history. One option is the abihty of a user to obtain a 
H single or multi-day daily route history for an individual vehicle or a group of 

p vehicles. Reports can contain multiple days of daily route histories. Thesjrstemis 

O 

il; flexible in accommodating any multiple day request. However, reports that range 

LfjlO from a single day to the past 31days are preferred. Daily route histories for 

M different days are displayed on separate maps or they can be displayed on a single 
map with an option to display up to five consecutive or non-consecutive days, with 

2 different icon shapes and colors to represent different days. 

The system includes an option that allows supervisory and management 
15 users to automatically receive a daily route history 1300 for the previous day for 
each technician and vehicle in their organization. Authorized supervisors and 
managers have the ability to specify the method of how the daily route history 1300 
is deUvered to themselves or any other user. 

Dehvery options for the daily route histories 1300 includes: (1) SMTP 
20 compliant e-mail dehvery to a specified address, with an Intranet-hnk utihty 
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attached to an e-mail message to move the user to the Intranet address for the 
report; (2) print file sent to a specified printer; (3) HTML formatted report file 
written to a specified directory, viewable using HTML version 1.0 or later; (4) 
HTML format file accessible on an Intranet system accessible by the user; or (5) no 
5 dehvery. In addition to the daily route histories 1300 being delivered, the system 
maintains, on-line, past daily route history information and at least retains the 

1^ most recent daily route history 1300 for each individual vehicle or technician. 

w 

p Figure 14 is an example of a route history report 1400. A route history report 

Sn 1400 is a summary of a vehicle's activities for a given time period. The time period 

iH 

'lO can be set as any desired period, examples of the time periods include one day or 

S5KCS 

nj one shift. The route history report 1400 can be displa3^ed or printed either in 

O tabular or graphical format. The invention includes provisions that allow users to 

switch between a tabular format and a graphical map-t3rpe format. The route 

history report 1400 provides the data, preferably in the form of item number, 
15 vehicle name, date, time, type, minutes (or the elapsed time spent at a particular 

location), speed, address, country (or any other pohtical sub-division) state and ZIP 

code, for the graphical route history shown in Figure 15. 

Figure 15 shows an example of a graphical route history 1500 according to 
the present invention. Graphical route history 1500 is preferably in the form of a 
20 map 1502 that shows the route 1504 traveled by the vehicle. Graphical route 

history 1500 can also include time and G.P.S. position information. In the example 
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shown in Figure 15, the time and G.P.S. position information is shown symbohcaUy 
with map icons 1506. Preferably, this information is overlaid or superimposed on a 
map so the location of the vehicle or technician can be observed with reference to 
geographical features. Graphical route history 1500 preferably includes a scale 
5 1508, a title 1510, and a key or legend 1512. Graphical route history 1500 is 

scalable and iisers can define or select various sizes of maps. The system can also 
automatically adjust the map so that all data points are included and the map is 
S produced at the highest possible resolution. Preferably, different icon shapes and 
m colors shall be used to indicate different points or vehicle attributes such as stopped 
HjlO vs. moving, alerts, and exceptions. 

1= Exception reports are reports that contain information related to exceptions 

E that have been logged by the system. Recall that exceptions are situations where 
U some attribute, characteristic, or data falls outside a predetermined parameter. 

The system allows authorized users to create reports that just list exceptions. 
1 5 These reports are called exception reports. The exception reports can include one or 

multiple technicians and the exception reports can be created for any desired 

parameter. 

An example of an exception report 1600 is shown in Figure 16. This 
exception report was created to hst or collect all instances where the speed of a 
20 vehicle exceeded sixty nine miles per hour. Thus, in generating this report, the 

speed parameter was set at sixty nine miles per hour, and any instances where the 
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speed of a vehicle exceeded sixty nine miles per honr (a value outside the 
boundaries of the parameter, and therefore considered an exception) the system 
collected that instance and included it in the exception report 1600. The exception 
report 1600 can include any relevant information. In the example shown in Figure 
5 16, the vehicle name, the date, the time, the speed and the name of the driver are 
included in the exception report. These items are generally relevant to the 
excessive speed exception and are therefore included. Similarly, other exception 
□ reports would contain information relevant to the exception being analyzed. 

ffi Exception reports can preferably be generated automatically, and dehvered to 

^10 the supervisor or manager. The method and time of exception report delivery can 
ni be configiired to suit the preferences of the recipient. Delivery options for the 
O exception reports includes: (1) SMTP comphant e-mail delivery to a specified 

address, with or without an Intranet-Unk; (2) utility attached to an e-mail message 
to move the user to the Intranet address for the report; (3) HTML format file 
15 accessible on an Intranet system; (4) print file sent to a specified printer; (5) "print 
to file" capability; or (6) no delivery. 

In terms of formatting, exceptions for all vehicles in a supervisor's 
organization for a single day are preferably contained on the same exception report. 
Both graphical and tabular formats of the daily route history for each vehicle with 
20 an exception is available. Preferably, these exception reports are accessed using an 
Intranet-link utihty attached to an e-mail message to move the user to the Intranet 
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address for the report. 

Figure 17 shows a current location report 1700. This report allows the user 
to quickly determine the location of a vehicle or a technician, like other reports, 
this report can be viewed on line or printed. The current location report 1700 can 
display a real time location of the vehicle or technician or can display a near real 
time location of the vehicle or technician. Real time displays provide more accurate 
location information but require sufficient computer resources to handle the large 
amount of information. On the other hand, near real time displays, displays that 
are delayed because position information is only transmitted at predetermined 
intervals of time, for example, one to ten minutes, are less accurate but also require 
less computer resources. Given these considerations, the system can be designed to 
optimize this trade-off between location accuracy and the need and expense of 
computer resources. A two minute location transmission interval is preferred. In 
other words, vehicles transmit their locations every two minutes to the central 
office. This also means that the preferred current location report 1700 displays the 
location of the vehicle two minutes ago. 

Referring to Figure 17, the current location report 1700 can include any 
desired information. Preferably the current location report 1700 includes a title 
1702, a map portion 1704, an icon 1706 representing the current location of the 
vehicle in question, a date and time stamp 1708, a vehicle identifier 1710, a 
technician's name 1712, a technician identifier 1714, the cellular telephone number 
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1716 of the vehicle, the pager number 1718 of the technician, the service center 
1720 where the vehicle originated, the technician's supervisor 1722, and the 
supervisor's pager number 1724* 

Administrative reports contain information associated with individual 
5 technicians or vehicles. One example of an administrative report, as shown in 

Figure 18, is a technician attributes report 1800. This report can be viewed on line 
Q or printed like other reports. The technician attributes report 1800 includes 
O information regarding a technician. The technician attributes report 1800 can be 
2 designed to suit particular needs. However, the preferred technician attributes 
r'io report 1800 includes a system title 1802, a title 1804 of the report, and a table 1806. 
m The table 1806 includes a technician's name 1808, the technician's social security 
p number 1810, a technician identifier 1812, the technician's pager number 1814, 
^ notes 1816 (in this case, the technician attributes report 1800 notes that the 

technician is diabetic), the vehicle number 1818 assigned to the technician, the 
15 cellular telephone number 1820 of the vehicle, the service center 1822 where the 
vehicle originated, the technician's supervisor 1824, the supervisor's pager number 
1826, and the technician's group 1828. 

The technician attributes report 1800 allows authorized users to enter 
corrections and easily submit updates directly onto the report, the technician 
20 attributes report 1800 includes a submit updates button 1830 that saves the 
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updates made by the authorized user. 



Any of the various disclosed components can be used alone, with other known 
components, or with features or components of the present invention. 

It will be apparent to those skilled in the art that various modifications and 
variations can be made in the GPS Management System of the present invention 
without departing from the spirit or scope of the invention. 

The foregoing disclosure of embodiments of the present invention has been 
presented for pxirposes of illustration and description. It is not exhaustive or 
intended to limit the invention to the precise forms disclosed herein. Many 
variations and modifications of the embodiments described herein will be obvious to 
one of ordinary skill in the art in hght of the above disclosure. The scope of the 
invention is to be defined only by the claims appended hereto, and by their 
equivalents. 
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